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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI). 

The present document is part 6 of a multi-part deliverable. Full details of the entire series can be found in 
TS 102 232-1 [2]. 

The ASN. 1 module is also available as an electronic attachment to the original document from the ETSI site (see 
clause A. 2 for more details). 
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Scope 



The present document contains service-specific details for the handover of the lawfully intercepted PSTN/ISDN 
Services (including emulated services such as those defined in ES 282 002 [3]) using packet-based techniques as 
defined in TS 102 232-1 [2]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 101 671: "Lawful Interception (LI); Handover interface for the lawful interception of 

telecommunications traffic". 

NOTE: Periodically TS 101 671 is published as ES 201 671. A reference to the latest version of the TS as above 
reflects the latest stable content from ETSI/TC LI. 

[2] ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific Details 

(SSD) for IP delivery; Part 1: Handover specification for IP delivery". 

[3] ETSI ES 282 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional 
architecture". 

[4] ITU-T Recommendation X.680: "Information technology - Abstract Syntax Notation One 

(ASN.l): Specification of basic notation". 

[5] Void. 

[6] ITU-T Recommendation G.71 1 (1988): "Pulse code modulation (PCM) of voice frequencies". 

[7] IETF RFC 4566: "SDP: Session Description Protocol". 

[8] ETSI TS 187 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Release 2 Lawful Interception; Stage 1 and Stage 2 
definition" . 

[9] Void. 

[10] IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 102 053: "Telecommunications security; Lawful Interception (LI); Notes on ISDN 

lawfull interception functionality" . 
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[i.2] 



ETSI TR 102 503: "Lawful Interception (LI); ASN.l Object Identifiers in Lawful Interception and 
Retained data handling Specifications". 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in TS 102 232-1 [2] and TS 101 671 [1] 
apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ASN.l 

cc 

CIN 
CSP 



Abstract Syntax Notation One 
Content of Communication 
Communications Identity Number 
Communications Service Provider 



NOTE: CSP covers all Access Providers, Network Operators and Service Providers. 

HI1 Handover Interface 1 (for Administrative Information) 

HI2 Handover Interface 2 (for Intercept Related Information) 

HI3 Handover Interface 3 (for Content of Communication) 

IP Internet Protocol 

IRI Intercept Related Information 

ISDN Integrated Services Digital Network 

LEA Law Enforcement Agency 

LEMF Law Enforcement Monitoring Facility 

LI Lawful Interception 

MF Mediation Function (at CSP) 

PDU Protocol Data Unit 

PES PSTN/ISDN Emulation Subsystem 

PSTN Public Switched Telephone Network 

RTP Real-time Transport Protocol 

SDP Session Description Protocol 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

UDP User Datagram Protocol 



4 General 

4.1 Approach 

The present document forms part 6 of the TS 102 232 family of standards, in that it is a service-specific component of 
the TS 102 232-1 [2] framework. 

For ISDN interception TS 101 671 [1] defines the interception behaviour that leads to visible IRI events on the 
handover interface. TR 102 053 [i.l] provides detailed guidance in support of TS 101 671 [1]. 

The present document provides a model for handover that may be used in conjunction with the interception domain 
specification TS 187 005 [8]. TS 187 005 [8] also provides an overview of the document structure within the NGN LI 
domain. 



ETSI 



ETSI TS 102 232-6 V3.1.1 (2012-06) 



4.2 



Reference model 




Network Mediation 
Function (MF) 



Law Enforcement 

Monitoring 
Facility (LEMF) 



Handover 
interface 



Figure 1 : Reference model 



Headers, data exchange and networks 



5.1 Approach 



TS 102 232-1 [2] describes a technique for data exchange, and specifies the headers that shall be associated with the 
results of interception. The present document follows TS 102 232-1 [2] regarding headers, data exchange and networks. 



5.2 



Structures 



IRI events from TS 101 671 [1] are sent using the structure ETSI671IRI. Supplementary information IRI (defined in 
clause 6.3) is sent using either the structure pstnlsdnlRI or the structure pstnlsdnCC (see clause A.2). CC is sent usin^ 
the structure pstnlsdnCC (see clauses 6.2 and A.3). 



5.3 



Definition of a communications session 



A new Communications Identity Number (or CIN) is assigned each time a new communications session begins. See 
TS 101 671 [1] for the definition of communications session. 

Typically, a new communications session is defined to begin (i.e. a new CIN is assigned) when each IRI-BEGIN 
message is sent (as listed in TS 101 671 [1]), then all further IRI and CC relating to that session has the same CIN. 
Typically, a REPORT record would form a communications session in its own right. If CC or an IRI record is generated 
for a session before the IRI-BEGIN is sent (e.g. through fault situations, or owing to unexpected latency), the CSP shall 
still ensure that all IRI and CC in the communication session has the same CIN. 



Intercept Related Information (IRI) and Content of 
Communication (CC) 



6.1 



Definition of IRI events and CC events 



IRI events are defined as per TS 101 671 [1]. CC is sent on all occasions that CC would be sent under TS 101 671 [1]. 
Further details for ISDN are provided by the state model and message sequence diagrams in TR 102 053 [i.l]; in 
particular see clause 6 of TR 102 053 [i.l]. 

6.2 CC format 

CC shall be expressed as an RTP frame. The CC shall also contain the RTP header, UDP header and IP header, except 
by agreement between CSP and LEA. 

NOTE: CSPs and LEAs may choose to omit headers because they are unavailable at the point of interception. 
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The Supplementarylnfo FrameType field indicates which headers are present in a given CC stream. If all headers are 
present, the FrameType field may be omitted. 

In the case where the RTP header is unavailable, one may be inserted by the mediation function, subject to agreement 
between LEA and CSP. The addition of an inserted RTP header may aid processing the audio stream at the receiver. 
When an artificial header is used, this shall be signalled using the artificialRtpFrame parameter of the FrameType 
structure. 

The content (i.e. RTP payload) shall be a complete, unmodified copy of CC information that is part of the target 
communication. 

The RTP header shall accurately describe the target communication. 

The information contained in the IP and UDP header does not necessarily relate to any media flow as seen by the target. 

IP and UDP headers shall not be inserted to the intercepted material by the mediation function if they are unavailable. 

If encryption has been applied within the CSP's domain and under their control, either it shall be removed or full details 
of the encryption including keys shall be supplied. 

Typically under PSTN/ISDN the codec used is ITU-T Recommendation G.71 1 [6]. The codec in use shall be signalled 
as described in clause 6.3. 

6.3 Supplementary information 

6.3.1 Requirements for supplementary information 

It is required that the LEA has enough information to decode and comprehend the traffic delivered over the Handover 
Interface. The following information is required: 

• Description of the format of the CC, to allow the LEMF to understand the information within the CC. 

6.3.2 Supplementary information 

Supplementary information is defined to be the following set of information. 



Field name 


Status 


ASN.1 field 


Information 


Media format 


Mandatory 


imediaFormat 


This field signals the codec used, as defined in 
RFC 3551 [10]. The supplementary info shall contain only 
one media format (send another supplementary 
information messages if the format changes). 


Media attributes 


Conditional 
(i.e. mandatory 
under the 
conditions 
listed) 


mediaAttributes 


If any extra information (beyond the Media Format) is 
needed to understand the delivered CC then it shall be 
sent here, in the format defined in the a= field of SDP (see 
RFC 4566 [7]). Typically, media attributes shall be present 
if and only if the media format is 32 or above. 


Encryption key 


Conditional 


encryptionKey 


See clause 6.2. 


Session name 


Optional 


sessionName 


If present in the target communication (e.g. SDP 's= field), 
it may be present in supplementary information as decided 
by national agreement. 


Session 
information 


Optional 


sessionlnfo 


If present in the target communication (e.g. SDP 'i= field), 
it may be present in the target communication, it may be 
present as decided by national agreement. 


Copy of SDP 
message 


Optional 


copyOfSDPMessage 


In addition to the above information, an SDP message may 
be included here. 



6.3.3 Sending supplementary information 



Supplementary information shall be sent as soon as possible for a communications session, and should be sent before 
CC is available. 
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If supplementary information is not available before the CC, under no circumstances shall CC be buffered or delayed. If 
supplementary information is critical to interpreting the CC, then CSPs shall ensure their systems are designed to avoid 
any delay in sending supplementary information. 

If the communications session contains traffic in more than one direction, then one set of supplementary information 
shall be sent for each direction present. Under some circumstances, the traffic sent in one direction will have a different 
set of supplementary information from traffic sent in the other direction (e.g. traffic to the target uses a different codec 
compared to traffic going from the target). Under these circumstances, the direction flag shall always be present and 
correct for all CC PDUs, and only the values "To Target" and "From Target" shall be used. 

If the supplementary information changes during a session (e.g. change of codec) then a new set of supplementary 
information shall be sent as soon as possible (it should be sent before the change occurs). It is required that the LEMF 
can identify the point in the CC stream at which the change took place. If it is not clear from the CC, then the CSP 
should populate the field "First PDU number" within the structure "InformationAppliesTo", to state the sequence 
number of the first CC-PDU to which the new supplementary information applies. 

Supplementary information shall be sent either as IRI or in CC-PDUs (in this case at least in the first PDU and in the 
following PDUs only if there are any changes during the session). 

6.3.4 Identification of CCLinks 

TS 101 671 [1] identifies certain occasions when different CCLinks are established (e.g. multi-party calls). 

If there are a number of different CCLinks (see TS 101 671 [1]), then one set of supplementary information shall be 
sent for each CC Link and the CCLinkID represent the CCLink that this information applies to. Within each CC Link, 
traffic in different directions shall be isolated and identified as described in clause 6.3.3. 

Note that the sequence numbering of CC-PDUs is not affected by the CCLink counter (i.e. do not maintain separate 
sequence number counts for separate CCLinks). 
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Annex A (normative): 
ASN.1 forlRlandCC 

A.1 Note on integrating ASN.1 structures 

IRI information structures are defined by the ASN.1 in TS 101 671 [1]. The headers that shall be applied to all IRI are 
defined in TS 102 232-1 [2]. There is some overlap between these structures, in that some fields which are present in 
TS 101 671 [1] IRI-Parameters are then repeated in the TS 102 232 PSHeader construction. In particular, there are the 
following overlaps: Lawful Intercept Identifier, Communication Identifier, TimeStamp. 

The present document follows TS 102 232-1 [2] for header information and requires that the TS 102 232 header shall be 
populated. For ease of interoperability the present document recommends that repeated fields should be populated in 
both the TS 102 232 and TS 101 671 [1] parts of the header. 



A.2 ASN.1 definitions 



The ASN.1 definitions are contained in a .txt file (PstnlsdnPDU, ver4.txt contained in archive 
ts_10223206v030101p0.zip) which accompanies the present document. 

The ASN.1 (ITU-T Recommendation X.680 [4]) module that represents the information in the present document and 
meets all stated requirements is shown below. TR 102 503 [i.2] gives an overview of the relevant Object Identifiers 
(OID) used in ASN. 1 modules of the Lawful Intercept specifications and points to the specification where the modules 
can be found. 



-- Description of the Pstnlsdn PDU 

PstnlsdnPDU 

{itu-t(O) identif ied-organization (4) etsi(0) securityDomain (2) lawfullntercept (2) li-ps(5) 
pstnlsdn (6) version4(4)} 

DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 

IMPORTS 

-- from TS 101 671 [1] 
IP Address 

FROM HI20perations 

{itu-t(O) identif ied-organization (4) etsi(0) securityDomain (2) lawfullntercept (2) hi2 (1) 
versionl6 (16) } 

-- from TS 102 232-01 [2] 
PayloadDirection 

FROM LI -PS -PDU 

{itu-t(O) identif ied-organization (4) etsi(0) securityDomain (2) lawfullntercept (2) li-ps(5) 
genHeader(l) versionl3 (13) } ; 



Object Identifier Definition 



-- definitions are relative to 

-- {itu-t(O) identif ied-organization (4) etsi(0) securityDomain (2) lawfulintercept (2) 

pstnlsdnlRIObjId RELATIVE-OID ::= {li-ps(5) pstnlsdn(6) version4(4) iRI(l)} 

pstnlsdnCCObjId RELATIVE-OID ::= jli-ps(5) pstnlsdn(6) version4(4) cC(2)} 
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Description of the Pstnlsdn IRI 



PstnlsdnlRI 



SEQUENCE 



pstnlsdnlRIObjId [0] RELATIVE -OID, 

pstnlsdnlRIContents [1] PstnlsdnlRIContents 



PstnlsdnlRIContents ::= CHOICE 

supplementarylnfo [0] Supplementarylnfo, 



Supplementarylnfo 



SEQUENCE 



informationAppliesTo [0] InformationAppliesTo, 

-- Identifies the PDUs to which this info applies 

mediaFormat [1] INTEGER (0..127), 

-- As defined in RFC 3551 [10] 

mediaAttributes [2] OCTET STRING OPTIONAL, 

-- Format as per RFC 4566 [7] 

-- Clause 6.3 describes when the mediaAttributes shall be present 

encryptionKey [3] OCTET STRING OPTIONAL, 

-- Format as per RFC 4566 [7] 

sessionName [4] OCTET STRING OPTIONAL, 

-- Format as per RFC 4566 [7] 

sessionlnfo [5] OCTET STRING OPTIONAL, 

-- Format as per RFC 4566 [7] 

copyOfSDPMessage [6] OCTET STRING OPTIONAL, 

-- Format as per RFC 4566 [7] 

frameType [7] FrameType OPTIONAL 

-- Populated if one or more protocol layers are missing from CC data 
-- May be omitted if all headers are present. 



InformationAppliesTo ::= SEQUENCE 

-- Identifies the PDUs to which a piece of supplementary information applies 

{ 

payloadDirection [0] PayloadDirection, 

-- The direction of the traffic to which this info applies 
cCLinkID [1] INTEGER (0.. 65535) OPTIONAL, 

-- If there are multiple CCLinks, this field states CCLink to which this info applies 
firstPDUNumber [2] INTEGER ( .. 4294967295 ) OPTIONAL, 

-- The supplementary info applies to all PDUs with this sequence number and above 



FrameType : : = ENUMERATED 

{ 

ipFrame ( ) , 






-- All headers are present 




udpFrame ( 1 ) , 




-- IP header is missing 




rtpFrame (2) , 




-- UDP and IP headers are missing 




audioFrame (3) , 




-- All headers are missing 




artif icialRtpFrame (4 ) 




-- UDP and IP headers are missing, 

} 


artificial RTP frame has been added 
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Description of the Pstnlsdn CC 



PstnlsdnCC ::= SEQUENCE 












i 


pstnlsdnCCOb j Id 
pstnlsdnCCContents 


[0] 
[1] 


RELATIVE -OID, 
OCTET STRING, 










-- See clause 6.2 for definition of format 


of Pstnlsdn 


CC 






cCLinkID 


[2] 


INTEGER (0. .65535) 


OPTIONAL, 








-- Shall be present 


if 


multiple CCLinks are used (see 


clause 


6.3.4) 




supplementary Info 


[3] 


Supplementary Info 


OPTIONAL 






} 


-- Shall be present 


at 


least in the first 


PDU 







END -- end of PstnlsdnPDU 
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Annex B (informative): 
Change request history 



Status of the present document: TS 102 232-6 
Service-specific details for PSTN/ISDN services; Handover specification for IP delivery 


TC LI approval 
Date 


Version 


Remarks 


September 2006 


2.1.1 


First publication of the TS after approval by ETSI/TC Lll#13 (6-8 September 2006, 
Stockholm) 

Version 2.1.1 prepared by Mark Shepherd (HO UK) (Rapporteur) 


April 2007 


2.2.1 


Included Change Request: 

TS102232-06CR001M (cat B) on Clarification of use of RTP/UDP/IP headers 

This CR was approved by TC Ll#15 (23-25 April 2007; Riga) 

Version 2.2.1 prepared by Peter van der Arend (KPN) (Chairman TC LI) 
Rapporteur of this specification is Mark Shepherd (HO UK) 


May 2008 


2.3.1 


Included Change Requests: 

TS102232-06CR002M (cat C) on Some comment and modification on the identification 

CCLinks defined in the clause 6.3.4 

This CR was approved by TC Ll#16 (2-4 October 2007; Berlin) 

TS102232-06CR003M (cat B) on Supplemetarylnfo in PstnlsdnCC 
This CR was approved by TC Ll#18 (27-29 May 2008; Chania) 

Version 2.3.1 prepared by Peter van der Arend (KPN) (Chairman TC LI) 
Rapporteur of this specification is Mark Shepherd (NTAC) 


May 201 2 


3.1.1 


Included Change Request: 

TS102232-06CR004M (cat B) on Addition of rtpframe parameter 

This CR was approved by TC Ll#30 (14-16 May 2012, Amsterdam) 

The ASN.1 definitions are contained in a .txt file (PstnlsdnPDU, ver4.txt) which 
accompanies the present document 

Version 3.1 .1 prepared by Peter van der Arend (Vodafone) (Chairman TC LI) 
Rapporteur of this specification is Mark Shepherd (NTAC) 
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